<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
	<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
	<TITLE>Readme for pipeline example</TITLE>
	<META NAME="GENERATOR" CONTENT="OpenOffice.org 2.0  (Linux)">
	<META NAME="CREATED" CONTENT="20061007;13053000">
	<META NAME="CHANGEDBY" CONTENT="kejin">
	<META NAME="CHANGED" CONTENT="20080215;19495900">
	<STYLE TYPE="text/css">
	<!--
		@page { size: 8.5in 11in }
		P { color: #000000 }
		H2 { color: #000000 }
		H3 { color: #000000 }
		PRE { color: #000000 }
		A:link { color: #0000ff }
		A:visited { color: #990066 }
	-->
	</STYLE>
</HEAD>
<BODY LANG="en-US" TEXT="#000000" LINK="#0000ff" VLINK="#990066" BGCOLOR="#ffffff" DIR="LTR">
<H2>PocoCapsule/C++ example: Basic-IoC Pipeline</H2>
<P>Copyright(c) 2007, 2008 by <A HREF="http://www.pocomatic.com/">Pocomatic
Software</A>. All rights reserved.</P>
<P>In PocoCapsule, the dynamic invocation proxies used in setup an
application are generated from application configuration
descriptions. Therefore, one does not need to regenerate and rebuild
these proxies if the configuration only changes by values of
parameter values. However, one usually needs to regenerate and
rebuild additional proxies if the configuration changes depend on new
dynamic invocation signatures. 
</P>
<P>To avoid the need of recompile dynamic proxies on the fields,
developers can pre-build all needed proxies for specific components
(or the specific application) using configurations that are used for
deployment testing. These proxies can even be built into their
associated business logic components. This example illustrates such a
component development and application deployment scenario. 
</P>
<P>In this example, two kind of components, namely <A HREF="MyNodeImplA.h">MyNodeImplA</A>
and <A HREF="MyNodeImplB.h">MyNodeImplB</A>, all support the common
<A HREF="Node.h">Node</A> interface. However, they are implemented
and built independently. Each of them is built together with its IoC
proxies into a dynamic library. These proxies are generated from
skeleton configurations (<A HREF="skelA.xml">skelA.xml</A> and
<A HREF="skelB.xml">skelB.xml</A>) that do not necessary have actual
configuration parameters. 
</P>
<P>Then, a pipeline application is setup (<A HREF="setup.xml">setup.xml</A>)
using these node implementations without the need of rebuilding
(generating and compiling) their dynamic invocation proxies. 
</P>
<H3>Source Files</H3>
<P><A HREF="main.C">main.C</A>: This is a simple mini container, used
to deploy the example application and push a message into the
pipeline from its upstream node.</P>
<P><A HREF="Node.h">Node.h</A>: This is the common interface of nodes
in the to be built pipeline application.</P>
<P><A HREF="MyNodeImplA.h">MyNodeImplA.h</A> and <A HREF="MyNodeImplB.h">MyNodeImplB.h</A>:
These are two different node implementations. 
</P>
<P><A HREF="skelA.xml">skelA.xml</A> and <A HREF="skelB.xml">skelB.xml</A>:
These skeleton configurations are used to generate dynamic invocation
proxies at development time. These proxies are built into the dynamic
libraries of their respective node component implementations, namely
MyNodeImplA.so/dll and MyNodeImplB.so/dll (see the makefiles listed
below). 
</P>
<P><A HREF="setup.xml">setup.xml:</A> This is the application setup
description. A (circular) pipeline is setup using the two kind of
node component implementations. This configuration is not used to
generate proxies but to be used to deploy/configure the application
immediately. 
</P>
<P><A HREF="Makefile">Makefile</A>, <A HREF="makefiles/Makefile.build">makefiles/Makefile.build</A>,
<A HREF="makefiles/Makefile.buildWindows_NT">makefiles/Makefile.buildWindows_NT</A>:
The linux and Windows makefiles to build this example. These
makefiles illustrate how to built components with their IoC proxies. 
</P>
<H3>Building this example</H3>
<P STYLE="font-weight: medium">To build this example, the environment
variable POCOCAPSULE_DIR should point to the PocoCapsule/C++
installed directory. Then, this example can be built by simply
invoking gmake/make on linux/unix or nmake on windows. 
</P>
<H3>Running this example</H3>
<P><FONT FACE="Symbol">&middot; </FONT><FONT FACE="Times New Roman">Before
starting the application deployment container (i.e. the main
executable), make sure the LD_LIBRARY_PATH (on linux and solaris) or
the PATH (on windows) environment variable is set correctly to
include the ${POCOCAPSULE_DIR}/lib directory.</FONT></P>
<P><FONT FACE="Symbol">&middot; </FONT><FONT FACE="Times New Roman">start
the main executable: </FONT>
</P>
<PRE STYLE="margin-left: 0.79in; margin-bottom: 0.2in"><B>prompt&gt;</B> main </PRE><P STYLE="margin-bottom: 0.2in">
<FONT FACE="Times New Roman">It will print out the following result:</FONT></P>
<PRE STYLE="margin-left: 0.79in">A::push(&quot;start&quot;)
B::push(&quot;start-&gt;A:upstream&quot;)
A::push(&quot;start-&gt;A:upstream-&gt;B:downstream&quot;)
B::push(&quot;start-&gt;A:upstream-&gt;B:downstream-&gt;A:upstream&quot;)
A::push(&quot;start-&gt;A:upstream-&gt;B:downstream-&gt;A:upstream-&gt;B:downstream&quot;)
B::push(&quot;start-&gt;A:upstream-&gt;B:downstream-&gt;A:upstream-&gt;B:downstream-&gt;A:upstream&quot;)
A::push(&quot;start-&gt;A:upstream-&gt;B:downstream-&gt;A:upstream-&gt;B:downstream-&gt;A:upstream-&gt;B:downstream&quot;)

start-&gt;A:upstream-&gt;B:downstream-&gt;A:upstream-&gt;B:downstream-&gt;A:upstream-&gt;B:downstream-&gt;end</PRE><P STYLE="margin-bottom: 0.2in">
<A HREF="../../README.html">Back to the root page</A></P>
</BODY>
</HTML>